System Center Configuration Manager и как с ним бороться

Как-то нам со свежеиспечённым ConfigMgr MVP было скучно и мы решили разобраться, как работает автообновление клиентов в 2012. Точнее, я сейчас готовлю второй видеоурок по установке клиентов, и метод automatically upgrade не описан в документации. Описание появилось несколько дней назад, но, опять же, довольно скудное.

Вова начал рыть внутрь, а я стоял рядышком и помогал.

Хочу обратить внимание, что это лишь наше личное мнение и функционал может работать не так, как мы считаем. Мало того, функционал может измениться с выходом SP1 RTM.

Итак, автоматическое обновление клиентов включается на уровне сайта и применяется ко всем клиентам иерархии. Версия клиента меняется при установке на сайт-сервер hotfix, CU или SP. Обновление включается Hierarchy Setting:

На вкладке видна последняя версия клиента и количество дней, в течение которых клиент после обновления политик должен обновиться.

После установки сайт-сервера, кроме пакета с клиентом, создаётся ещё и пакет с обновлением, который: а) скрытый; б) автоматически добавляется на точки распространения. Его ID на единицу больше ID пакета клиента и его можно увидеть под именем Configuration Manager Client Upgrade Package в статусе контента:

После включения автообновления сайт-сервер формирует новую политику, которую и скачивает клиент в стандартном цикле запроса политик на компьютер.

Что можно наблюдать в ccmsetup.log на стороне клиента:

Launch from folder C:\Windows\ccmcache\z\, cache C:\Windows\ccmsetup\cache\
CcmSetup version: 5.0.7782.1000
Ccmsetup command line: «C:\Windows\ccmcache\z\ccmsetup.exe» /AutoUpgrade /UpgradePackageVersion:4
Loaded command line: «C:\Windows\ccmcache\z\ccmsetup.exe» /AutoUpgrade /UpgradePackageVersion:4
The MP name retrieved is ‘sccm12.firma.local’ with version ‘7782’ and capabilities ‘<Capabilities SchemaVersion=»1.0″><Property Name=»SSLState» Value=»0″/></Capabilities>’
MP ‘sccm12.firma.local’ is compatible
Retrieved 1 MP records from AD for site ‘FFF’
Found MP http://sccm12.firma.local from AD
Autoupgrade without specifying action mode. Will run as service.
Searching for DP locations from MP(s)…
Found local location ‘http://sccm12.firma.local/SMS_DP_SMSPKG$/ZZZ00002′
Last auto-upgrade config time(utc) ’10/31/2012 12:05:41 PM’. Using 1 days to randomize.
Upgrade task is randomized to run at 10/31/2012 11:06:04 PM UTC time with arguments ‘ /AutoUpgrade /UpgradePackageVersion:4 /UpgradeWinTask’.
Successfully deleted existing ccmsetup.exe
Downloading file C:\Windows\ccmcache\z\ccmsetup.exe
Downloading C:\Windows\ccmcache\z\ccmsetup.exe to C:\Windows\ccmsetup\ccmsetup.exe

Лог приведён неполностью.

Итак, происходит следующее.

Клиент проверяет свою версию в WMI и вычитывает из политики, что есть более свежая версия, чем уже установлена. Ищет точку управления, запрашивает у неё адреса точек распространения, у которых есть пакет с обновлением клиента, обращается к ней и стаскивает ccmsetup.exe свежей версии себе в кэш:

После получения политик создаётся hidden deployment(?), о котором клиент узнал от сайт-сервера, и в Task Scheduler появляется новое задание с обновлением и случайно выбранным расписанием в пределах того количества дней, которое указано в Hierarchy Settings:

Новый ccmsetup.exe из кэша перекрывает ccmsetup.exe в C:\Windows\ccmsetup и запускается с ключами /AutoUpgrade /UpgradePackageVersion:4 /UpgradeWinTask.

Вова, думаю, в комментариях добавит то, что я упустил.